Gaming system with failover and takeover capability

ABSTRACT

Managing failover and takeover of a game session in a computerized gaming system adapted for operating a plurality of client gaming machine terminals communicatively coupled to one of a plurality of game application servers, comprising: sending a request of a game session from a client gaming machine to a first game application server; determining in the client gaming machine non-responsiveness to the request; re-transmitting the request from the client gaming machine to a second game application server; constructing the game session state in the second game application server; processing the request in the second game application server; and sending a response dependent on the request from the game application server to the client gaming machine.

RELATED APPLICATION

This application claims priority to, and is a continuation of,International Application No. PCT/SE2006/000559, having an internationalfiling date of May 12, 2006, and U.S. patent application Ser. No.12/269,393, filed on Nov. 12, 2008, which are hereby incorporated byreference herein in their entirety.

TECHNICAL FIELD

The present invention relates generally to the management of failoverand takeover in a computerized game of chance operated via gamingmachine terminals in a computerized gaming system. In particular, thepresent invention relates to a system that enables failover and takeoverwith the preservation of an on-going game session.

BACKGROUND

In computerized gaming, involving casino game or lottery game types,there is usually a bet and a possible winning prize payback at stake. Aplayer may be about to win when interruption occurs and thus may bedeprived of his winning play or his payout if the game is not resumedafter the interruption. Gaming systems are usually also subject tostrict control from authorities that require game record keeping foraudit purposes, and it is not acceptable for game records to deviatefrom factual payouts. It is therefore important for the credibility ofthe gaming operator to manage interruption and game resumption in asecure and correct manner.

In computerized gaming systems where gaming machines, for example slotmachines or poker machines, are connected to a game server there are forinter alia the above reasons high demands on the uptime and theoperability of the system. The gaming system must be insensitive tointerruptions in communications between the gaming machines and the gameserver.

Computerized gaming systems have traditionally been designed with a highlevel of local autonomy on the part of the gaming machine in relation tothe game server. As a consequence, the possibility to rationalize themanagement of gaming system by means of common server resources has beenutilized only to a small extent. There is a need for improving theefficiency of computerized gaming systems, and one way to do this is byincreasing the usage of the server resources. Consequently there is aneed for increasing the reliability and availability of these serverresources.

RELATED ART

The present invention makes use of prior art disclosed in the co-pendingbut not yet published patent application no PCT/SE2005/001716 by thesame applicant as the one for the present application. The content ofPCT/SE2005/001716 is herewith incorporated by reference.

Further examples of prior art are found in the following patentpublications.

WO 2005/026909 A2 claims to disclose a system and method for gamingsystem configuration and control in a gaming environment. Certainembodiments include receiving a request for an application to execute ata gaming system, and routing the request to an appropriate applicationserver to provide the application at the gaming system. The request maybe routed based on a status of a plurality of application servers, forexample. The method may also include verifying that the gaming system isauthorized to execute the application. In an embodiment, the methodincludes distributing a request for data among a plurality of databaseservers.

US 2004/0002385 A1 claims to disclose a gaming communication networkwith an enhanced DCU that provides redundant mediation between gamingmachines on the gaming communication network and a host server. Theenhanced DCU provides a first, primary transmission path and a second,redundant transmission path between the gaming machines and the hostserver. In the event one transmission path is disrupted, the otherprovides continuing transmissions between the gaming communicationnetwork and the host server. In the event both transmission paths aredisrupted, the enhanced DCU functions as a local interim server andstores data received from the gaming machines on the gamingcommunication network until such time as the data can be transmitted tothe host server. In some embodiments, the enhanced DCU acts as a localinterim server to the gaming machines using data mirrored from the hostserver prior to transmission disruption. In some embodiments, theenhanced DCU functions as a download server, stores data received fromthe host server, and asynchronously transmits the data to the gamingmachines, so as to mitigate disruption of game play. In someembodiments, the enhanced DCU may also function as a local cache ofinformation that is repeatedly accessed by the gaming machines on thegaming communication network so as to reduce the transmission load onthe first and/or second transmission path.

US2005/0198335 A1 claims to disclose a method and system fordistributing work load in a cluster of at least two service resources.Depending upon the configuration, a service resource may be anindividual process, such as a single instance of a computer game, or anode on which multiple processes are executing, such as a Server.Initial connection requests from new clients are directed to a singleentry-point service resource in the cluster, called an intake. Aseparate intake is designated for each type of service provided by thecluster. The clients are processed in a group at the service resourcecurrently designated as the intake to which clients initially connected,for the duration of the session. Based upon its loading, the currentintake service resource determines that another service resource in thecluster should become a new intake for subsequent connection requestsreceived from new clients. Selection of another service resource tobecome the new intake is based on the current work load of each resourcein the cluster. All resources in the cluster are periodically informedof the resource for each service being provided that was last designatedas the intake, and of the current load on each resource in the cluster.Subsequently, new clients requesting a service are directed to the newlydesignated intake for that service and processed on that resource forthe duration of the session by those clients.

JP2002055904 claims to disclose a game contents providing server thatseeks to enable the playing of a game continuously even if a connectionis cut off carelessly. A game contents providing server 1 is connectedto a computer network 5 composed of computer terminals 3 connectedtogether in a communicable state. The server provides registered gamecontents so that access users can play the game and is equipped with agame state registering means 15 which obtains information specifying anaccess user and registers game state data of a game in case ofdisconnection. If the access user is disconnected during the game andthe access user gains access again, then the game state is distributedto the computer terminal 3 of the access user according to theregistered game state data so that the user can carry on the game.

WO02098526 A1 claims to disclose an apparatus and method fordistributing a multi-client system (10) over a communications network(40) for use in games and other applications. The system (10) includes aplurality of servers 14, 16, 18) each associated with one or moreclients (32,34,36,38). A set of data (102,112, 122) is maintained oneach server for each client/object, and an interaction data set for eachnon-associated client/object (clients/objects on another server)(104,106,114,124,26) is transmitted to other servers to provideinter-server mirroring or duplication of data. The interaction data setis a subset of the set of data for each client/object. Volumes, eachdefined by a set of coordinates, managed by each server (204) aredynamically allocated to manage server load based upon the number ofclients/users associated with the volumes.

US 20040219967 A1 claims to disclose a method to pause a game played viaa first gaming machine and resuming the game via the same gaming machineor via another, second gaming machine. The status of a paused game isstored at a central database linked to the gaming machines and isassociated with a personal identifier of the player. To continue apaused game, the game play is continued by retrieving the game statusfrom the central database in response to the input of the associatedpersonal identifier via the same or another gaming machine.

These pieces of prior art show varieties of technical solutions relatedto the handling of interruptions in the communication between a gamingmachine and a game server.

OBJECT OF THE INVENTION

It is an object of the present invention to provide a system for themanagement of failover and takeover in a computerized gaming system. Inparticular it is an object to provide such a system that enablesfailover and takeover with the preservation of an on-going game sessionof a computerized game of chance operated in a computer based gamingsystem with computerized gaming machine terminals that are connected toa remote central game server.

SUMMARY OF THE INVENTION

In accordance with the invention the object is achieved by providing aplurality of redundant game application servers that are communicativelycouplable to client gaming machines for operating a game session bymeans of a client game module and a server game module. The gameapplication servers are redundant in the sense that they are devisedsuch that any of them is capable to be coupled to a client gamingmachine and operate the applicable game session. During an on-going gamesession the client gaming machine sends requests to a coupled gameapplication server and receives responses from the game applicationserver, and matching states are created on the client side and theserver side respectively. In the course of the game session, gamesession data is stored in a game server database. If there is aninterruption and thus a failure in the capability or possibility toreceive such a response in the gaming machine, the operation of theserver part of the game session is moved to a different game applicationserver. This is achieved by, in response to detecting that no responsewill be received from the first game application server, directing thecommunication from the client gaming machine to an available second gameapplication server and reconstructing the game session in the secondgame server. For the purpose of game session reconstruction the storedgame session data associated with the current game session andidentified with a game session identification code comprised in thecommunication from the client gaming machine is retrieved from the gameserver database. The game session, or at least the server part of thegame session, is re-executed and thus reconstructed up to the point ofinterruption, i.e. to the last and un-responded request. The second gameapplication server generates a response to this request, in the samecontext and with the same input data as for the original request thatwas un-responded by the first game application server, and from thereonthe operating of the game session continues with a different pairedcouple of a client gaming machine and a game application server. Thisfailover-takeover procedure thus manages the failure in response from afirst game application server during an on-going game session and thetakeover of the server part of the game session operating by a secondgame application server. The failover-takeover procedure is preferablyexecuted in a manner that is invisible to the player of the gamesession. The time delay is normally in the range of fragments of secondsand the player usually never notices any interruption. The interruptionmay for example be due to communication failure between the clientgaming machine and a game application server or between a gameapplication server and a game server database, as well as functionalfailure of the game application server or the game server databasecoupled to it. A technical effect of this is that any land ofinterruption or failure in the operation on the server side, the gameapplication server as well as the game server database, is managedwithout interrupting the game session as experienced by the player or bythe operator. A further technical effect is that the game developers donot have to address these interruption cases when developing the gamesoftware.

According to an aspect of the invention the failover-takeover capabilityis utilized for introducing or taking down a game application server ora game server database during operation of the gaming system. Thetechnical effect of this is that it renders scalability andserviceability to the system during 24 hours, 7 days a week (24×7)operation. Seamless removal of game application servers or game serverdatabases for maintenance or upgrading as well as addition of gameapplication servers whenever needed thus is enabled by the presentinvention.

According to another aspect of the invention there is enabled managingof redundancy of server side functions in the gaming system during 24×7operation. Game application servers or game server databases are thusenabled to take over sessions from application servers or game serverdatabases that have gone out of order or lost network communicationconnections without any need for players or client gaming machines totake any particular action.

According to a further aspect of the invention there is enabled loadbalancing in a high load operational environment of the gaining systemduring 24×7 operation.

Other aspects and advantages of the invention are described in the belowdescription. The invention is preferably realized as a method, a systemand a computer program product.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS

The inventive concept is further explained by means of examples and inconjunction with the accompanying drawings, in which:

FIGS. 1A and 1B show schematically embodiments of client-server basedgaining system with failover-takeover capability according to anembodiment of the invention.

FIG. 1 C shows a schematic outline of the functions in a client-serverbased gaming system according to an embodiment of the invention.

FIG. 2 shows a flow chart of a simple example of a gaming application.

FIG. 3 shows a variety of the gaming system in accordance withembodiments of the invention.

FIG. 4 shows a schematic view of different phases of a game.

FIG. 5 shows a schematic sequence diagram that illustratescommunications between a gaming machine/client game module and a remotedata storage/server game module.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The figures illustrate the configuration of a gaming system as well as amethod and a computer program product for managing failover and takeoverin accordance with the invention. The described method steps andfunctions are realized by means of computer system components, computersoftware code portions, or by means of combinations thereof. It iswithin the knowledge of the skilled person to select appropriate meansand combination of means for the realization of the invention.

Preferred Embodiment of Gaining System with Failover and TakeoverCapability

FIG. 1A shows schematically an exemplifying embodiment of aclient/server based gaming system 101 with failover and takeovercapability in accordance with the invention. A first client gamingmachine 102 is communicatively coupled to a first game applicationserver AS1 106 and to a second game application server AS2 108. Thefirst and second game application servers are in their turncommunicatively coupled to a game server database 110 comprising adatabase application logic layer 111 and a database storage structureGSDB. Communicatively coupled in this text means that there is provideda communication link over which information signals can be communicatedbetween two coupled units, for example in the form of messages or datastreams. The communication link can for example b e continuouslyactivated in an on-line state or be activated on request when a message,e.g. in the shape of a request or a response, is communicated. In asimple form the gaming system in accordance with the invention comprisesa single client gaming machine, at least two game application serversand a game server database.

The gaming system according to the present invention is based on aclient/server architecture where the game software is divided into aclient game module and a server game module with access to a centraldatabase. In order to run a game the client game module must beassociated with and use functions available at a server game module.When a game is played via a client gaming machine, a game session isestablished and game session data is generated in the course of thegame. Each game session has a specific identity and is assigned a gamesession identity code. The game session data is stored in the gameserver database associated with the game session identity code and insome embodiments also with a reconnect identity code. The game sessiondata comprises all the data that is necessary to reconstruct a gamesession as a whole or up to a certain point with the same result,outcome and output as the original game session. The operation of thisspecific land of client/server gaming system and the game sessionreconstruction solution is explained in more detail below.

In the example of FIG. 1A there is also a second client gaming machine104 that similarly is communicatively coupled to the first and secondgame application servers. The client gaming machines 102 and 104 areprovided with means 112 and 114, respectively, for selecting one gameapplication server to communicate with according to predetermined rulesof priority and for directing the communication according to theserules. The client gaming machines 102, 104 are further provided with amechanism 103 devised to determine dependent on predetermined receivingcapability rules whether a response is capable of being or possible tobe received from the game application server within a predeterminedreceiving condition. The receiving condition is one embodiment receiptwithin a selectable predetermined amount of time. In this case thepredetermined amount of time can be coordinated with a normal functionof timeout of predetermined accepted response time, for example suchthat the time of the receiving condition is shorter than the acceptedresponse time that is configured for the client gaming machine so thatthe game session can be preserved on the client side during theoperation time for the failover and takeover operations.

In another embodiment the receiving condition is a predetermineddependency on a status parameter, for example a parameter that describesthe status of the communication link, the game server, some otherfunctionality or control parameter of the gaming system. In a furtherembodiment, the receiving condition is dependent on a predeterminedquality of response from the game application server, for example theresponse may be erroneous or inconsistent with the request, or maycommunicate a request from the server side to trigger a takeover by adifferent game application server for example due to maintenance. Therequest to trigger a takeover may also have the form of a switch offsignal or a command to a game application server or a game serverdatabase, and is an optional feature in an embodiment of the invention.

The client gaming machines 102, 104 further preferably comprises means105 devised to initiate re-transmit of a request in response to negativereceiving capability being determined, and to initiate selecting andre-directing to a different game application server.

The direction priority rules are used to establish communication of theclient gaming machine with the game application server that has thehighest priority. If such communication fails, the client gaming machinetries to communicate with the game application server that has the nextlevel of priority and so. In this example the first client gamingmachine 102 is adapted to communicate with the first game applicationserver 106 with first priority and with the second game applicationserver 108 with second priority. Conversely, the second client gamingmachine 104 is adapted to communicate with the second game applicationserver 108 with first priority and with the first game applicationserver 106 with second priority. In this manner the client gamingmachines have alternative game application servers to communicate within case the communication path or the first selected game applicationserver for some reason are inoperative for the purpose of the clientgaming machine.

The game application servers 106, 108 are coupled to a game serverdatabase 110, which may be a common game server database 110 as shown inFIG. 1A or separate game server databases. However, in a system withfailover and takeover capability there is provided at least one reservegame server database 116, comprising a database application logicallayer 117 and a game server database storage structure GSDB, adapted tobe switched into communicative coupling with the game applicationservers to substitute a first game server database for example in caseof operational failure or when it is intentionally taken out ofoperation. The game server database 110,117 is further communicativelycoupled to a back office database 118, similarly comprising a databaseapplication logic layer 119 and a database storage structure BODB.

FIG. 1B shows an embodiment of a client/server based gaming system withgroups of client gaming machines 120, 121, 122 communicatively coupledto a load balancer 124. The load balancer is in its turn communicativelycoupled to a plurality of game application servers. A first group ofgame application servers AS 13, AS 12 . . . AS IN are communicativelycoupled to a first game server database 132 with database applicationlogic layer 133 and a database storage structure GSDB1, and a secondgroup of game application servers AS21, AS22 . . . AS2N are coupled to asecond game server database 134 with a database application logic layer135 and a database storage structure GSDB2. The first and second gameserver databases 132,134 are in their turn communicatively coupled to asingle back office database 136 comprising a database application logiclayer 137 and a database storage structure BODB1. The coupling to theback office database is a single entry point and functional redundancyis achieved by providing a second back office database 138 with adatabase application logic layer 139 and a database storage structureBODB2 to which the single entry point coupling can be switched in casethe first back office database BODB1 is out of order or is taken out ofoperation.

The information stored in the game server database has a transactionalnature and inter alia comprises information pertaining to game sessions,game session data, game session identity, client gaming machineidentity, etc as the game sessions are operated and executed. Thisinformation is preferably cashed, i.e. temporarily stored, in the gameserver database and is continuously or intermittently transmitted andstored in the back office database, and then deleted from the gameserver databases. The back office database is thus used to storeselections of historical data from the transactions, possibly in adifferent format than in the game application server.

In the shown embodiment the mechanism 103 for determining the capabilityof receiving in the gaming machine a response to the request from thefirst game application server within a predetermined receiving conditionis optionally provided in the load balancer 124. The load balancer alsocomprises means 126 for selecting a game application server for theclient gaming machines to communicate with according to predeterminedpriority rules, and means 128 for directing the communication to andthus to establish communicative coupling with a selected gameapplication server. Normally, a specific client gaming machines wouldalways be directed to the same game application server. But as describedabove, the means 105 for initiating re-transmit, selecting andre-directing comprised in the client machines 120,121,122 is activatedin response to negative receiving capability being determined, andinitiate selecting and re-directing a re-transmitted request to adifferent game application server.

So for example, in one embodiment the priority rules are devised tocouple a gaming machine from the first group of client gaming machines120 to a game application server from the first group of gameapplication servers AS11, AS12 . . . AS1N with a first priority and to agame application server in the second group of game application serversAS21, AS22 . . . AS2N with a second priority, and similarly for thedifferent groups of client gaming machines and game application servers.The selection of game application server within or between the groups isalso controlled by means of the priority rules according to any suitablepredetermined scheme known in the art, for example, dependent onprocessing load, number of active game sessions, a round robin scheme, arandomized selection or plain availability for communication.

In an exemplifying simple case of failover-takeover management when agame session is about to be established and a client gaming machineseeks communicative contact with a game application server, the clientgaming machine sends a request to the game application server and awaitsa response. The receiving capability mechanism determines whether aresponse is capable of being or possible to be received from the gameapplication server within the current predetermined receiving capabilitycondition, for example within a predetermined amount of time. If it isdetected that the response from the first contacted game applicationserver will not be received by the client gaming machine within, in thisexample, the predetermined time, the communication is directed to thesecond game application server in accordance with the predeterminedrules of priority and the request is sent anew to the second gameapplication server. In this initial communication phase before a gamesession has been established, the failover-takeover function is thusrealised by making contact with and using an alternative gameapplication server for the game session.

In the case when a game session is established and executed thefailover-takeover function is more complex. The procedure for failoverand an inherent takeover function comprises in one embodiment aselection of the following steps.

1. A client gaming machine is thus operating a game session that isassociated with a game session identity code via said client gamingmachine and a first game application server.

2. As the game session is operated and executed, game session data ofsaid game session is stored in the game server database associated withthe game session identity code. Selected information about the gamesession is preferably also stored in a back office database.

3. In the course of operating the game session, requests arecommunicated from the gaming machine to said first game applicationserver.

4. For each request it is determined the capability of receiving in thegaming machine a response to the request from the first game applicationserver within a predetermined receiving condition.

5. If the capability of receiving a response from the first gameapplication server is determined not to be fulfilled within saidpredetermined receiving condition, then measures are taken according tothe following steps. If on the other hand the capability of receivingthe response is fulfilled within the predetermined receiving condition,then the operating of the game session continues in a normal manner.

6. The client gaming machine is in one embodiment devised to re-send itslast request to the first game application server for a predeterminednumber of times or during a predetermined amount of time, in response todetermining said lack of receiving capability. This preserves theoriginal coupling between the client gaming machine and the first gameapplication server, and the game application server handle re-transmitsby cashing the last generated response and resend the response if itcorresponds to the re-sent request. This can be implemented as a levelof the predetermined receiving conditions.

7. A second game application server for operating the server part of thegame session is selected dependent on predetermined priority rules.

8. The client gaming machine is communicatively coupled to the selectedsecond game server.

9. A request associated with the game session and comprising said gamesession identity code is communicated from the gaming machine to saidsecond game server.

10. The second game application server receives the request from theclient gaming machine, possibly together with failover status indicatordata, and determines that it does not currently operate the game sessionrelated to this request.

11. The second game application server communicates a request to thelogic layer of its related game server database (second game serverdatabase) and requests information about the game session that isassociated with the game session identity code. The requestedinformation is for example the identity of the first client gamingmachine.

12. If the first game application server was related to a different gameserver database (first game server database), then the second databasecommunicates with the first database and requests the information aboutsaid game session. In order to find the identity of the first gameserver database, the second game application server may request thisinformation from the back office database if applicable.

13. Dependent on the thus requested information about the game session,it is determined by one of the game server database or by the secondgame application server whether a takeover of the game session from thefirst game application server is possible. For example, it is notpossible to take over a game session if there is some on-goingprocessing related to a request in the original game application serveror game server database. This makes sure that the same request,pertaining to the same game session, is not processed or operatedsimultaneously by two game application servers or game server databases.

14. If takeover is determined to be possible, then the game session istaken over, if applicable, by the second database from the firstdatabase without involving the second game application server and thentaken over by the game application server. Alternatively, if only onegame server database is involved, the game session is taken overdirectly by the second game application server.

15. If the first game application server is communicatively capable,e.g. being in an online state, then one of said game server databasessends a notification that the game session has been taken over by asecond game application server. The game application servers are devisedto remove any cached data for such a taken over game session in responseto such a notification in order to avoid working on stale data.

16. The game session data that is stored associated with said gamesession identity

code is retrieved from the game server database by the second gameapplication server.

17. The game session is reconstructed by means of the retrieved gamesession data. In a preferred embodiment, only the server side of thegame session is reconstructed and the client side of the game sessionremains intact. The reconstruction of the game session is carried out bymeans of functions for reconnect handling described in more detailbelow.

18. The operating of the game session is continued via said clientgaming machine and said second game application server.

General Setting of Client/Server Gaming System

FIG. 1C shows schematically a client and server based computerizedgaming system with a gaming machine 2, herein also called a videolottery terminal, set up as a client gaming machine 2 and a gameapplication server 4 that are communicatively coupled. The gamingmachine 2 and the game application server 4 are provided with dataprocessors, memory means, data communications interfaces, controlprograms, user input/output interfaces etc. in a per se well knownmanner. Different functions and features that are specific for thepresent invention are preferably realised by means of software computerprogram code executed on the server and the client respectively, bymeans of specifically designed electronic components or by means ofcombinations of software and electronic components. In the example ofFIG. 1C there is only a single client gaming machine but of course anumber of client gaming machines can be and are normally connected to aserver as shown in FIG. 1 A.

The server 4 is provided with a game application program interface(server game API) 6 enabling communication between a server module of aspecific game application program 8 and general server gaming functions10,12,14,16 installed on the server. The general server gaming functionsare provided to be available for any specific game application programindependently of the specific game content. These general server gamingfunctions are typically critical functions such as a database 10, arandom number generator 12, an account service function 14, a logservice function 16, or other functions that beneficially are shared andused by different specific game application programs. In differentconfigurations of the invention, the mentioned general server functionsmay be integrated with the server or be configured as separate entitiesthat are communicatively coupled to the server. For example, the gameserver database is in preferred embodiments a separate entity providedwith a logical database application layer.

The client gaming machine 2 is also provided with a game applicationprogram interface (client game API) 20 enabling communication between aclient game module 18 of the specific game application program andgeneral client gaming functions 22,24,26,28 installed on the clientgaming machine 2 and used by different client game modules. The generalclient gaming functions are designed for assisting in implementing andexecuting a specific game on the client gaming machine 2 and areavailable for the client game module 18. These general client gamingfunctions are in different embodiments a selection of a graphical userinterface GUI 22, a cashbox function 24, a sound function 26, user inputinterface function, for example buttons, 28, data storage 29, a printer3, a bar code reader 33 and other functions that are related to theperformance of a game. The client game module 18 is communicativelycoupled to the corresponding server game module 8 for communicatingrequests 9 and responses 11 in order to utilize the general gamingfunctions provided in the server. For each game a message protocol forcommunication between the client module and the server module isgenerated, the protocol is for example based on XML and is shared by theclient and the server.

A specific game application program in accordance with the inventionthus comprises a server game module 8 and a client game module 18 thatcommunicate either directly or via an application program interface onthe client side and the server side respectively as shown in FIG. 1C andFIG. 3. The client game module 18 uses a selection of general clientgaming functions that are available in the client gaming machine,whereas the server module 8 uses a selection of general server gamingfunctions 10,12,14,16 that are commonly used by different gameapplications and that are provided and available centrally in the server4.

FIG. 3 shows a more detailed view of the configuration of a client and aserver in a gaming system in accordance with an embodiment of theinvention and similar to that of FIG. 1. In the game application server4 the server game module 8 is embedded behind an application programinterface called server game API 6 through which all communication ofthe server game module 8 takes place. The game application server 4further comprises a server application program interface in short calledserver API 40 through which all communication with the general servergaming functions 10,12,14,16 from the part of the server game API 6 aswell as from the part of other server functions and externalcommunication takes place. The server 4 is further provided with areconnect handler 32 that in a preferred embodiment is integrated withthe server game API 6. The game application server 4 is provided withfurther server function modules, in the exemplifying embodiment morespecifically comprising a client handler 36 that is communicativelycoupled to the server API 40. The client handler 36 manages, i.e. interalia comprising handling and serving, communications and functions ofthe client 2 other than the specific game applications. As illustratedin the drawing with a double arrow, communications with the clientgaming machine 2 takes place via the server API 40 and a similar clientAPI 38 provided in the client gaming machine 2. In the same manner asdescribed above, the communication with the general client gamingfunctions is carried out via the client API 38. The client gamingmachine 2 comprises a client control module 34 that controlscommunications and general functions of the client gaming machine otherthan the specific game applications and communicates via the client API38. hi the gaming client 2 the client game module 18 is, similar to theconfiguration of the server, embedded behind an application programinterface called client game API 20 through which all communication ofthe client game module 18 takes place. The client 2 is further providedwith a reconnect handler 30 that in a preferred embodiment is integratedwith the client game API 6.

FIG. 2 shows schematically a simple example of a portion of a gamingapplication in accordance with the invention, more particularly a flipcoin game of chance. The game is run by executing the client game module18 and the general client gaming functions of the flip coin gamingapplication in a client gaming machine in step 202. In step 204 theplayer is presented a message asking the player to bet on heads ortails. The player places a bet 206 and a result is calculated in 208.Step 208 involves the client game module 18 sending a request to theserver game module 8 to generate an outcome of the game. The server gamemodule in its turn calls the random number generator 12 and receives arandom number in return. The server game module calculates an outcomeaccording to predetermined rules for the game and dependent on thereturned random number. Thereafter, a response with the outcome Win orLose is communicated back to the client game module. If the outcome isLose 210 the player is presented a message showing that player lost 212,and the game is ended in 214. If, on the other hand the outcome is Win216 the player is presented a message asking player to collect the prizeor double a bet again 218. If the player inputs a request to Double 224,a new result is calculated in 208 in the above manner. If on the otherhand the player inputs a request to Collect 219, the prize, usually inthe form of cash or credit money, is paid to the player and the gameends in 222. The payout of a prize again preferably involves requestingservices from the server game module and for example utilizing thegeneral server gaming functions account function 16 and databasefunction 10.

Preferred Embodiment of Interruption and Reconnect Management

In accordance with the inventive concept, interruption or abnormaltermination of a player session during playing a game is handled bymeans of mechanism for reconstruction of a game session herein alsocalled a reconnect function. The reconnect function is managed bystoring the previous game configuration in the server database at thebeginning of each game round. All user interactions and inputs thatoccur during the game round as well as the random numbers that weregenerated are stored in the server database associated with a gamesession identity code. When a player session or a game session isterminated abnormally a reconnect voucher is created by the clientgaming machine and output to the user. The voucher comprises accountbalance information and a reconnect identity code, that is coupled withor identical to the game session identity code and that is used toidentify the interrupted game. The player can thereafter request areconnect by inputting the voucher to the same or another gamingmachine. The game is initialised with the game session properties thatwere stored at the beginning of the round and retrieved from thedatabase by means of the Voucher identity code, and the interrupted gamesession is reconstructed up to the point of interruption. Thus thereconnect function enables the player to continue the game at the samestage as when interrupted.

In connection with the failover-takeover procedure, the mechanism forreconstruction of a game session is applied in the background of thesystem and is preferably invisible to the player. For example noreconnect voucher is issued. In the voucher case, reconnect and gamesession reconstruction is initiated by the client gaming machine inresponse to a received voucher. In the failover and takeover case, thegame session reconstruction and reconnect is initiated from the secondgame application server that is contacted and receives a re-directedrequest belonging to an on-going game session. If the failover andtakeover procedure for some reason fails, the game sessions isinterrupted also in the client gaming machine and a reconnect voucher isissued. The failover-takeover procedure utilizes a selection of thesteps, functions and means described herein in the context of reconnectof a fully interrupted game session however suitably adapted to thefailover-takeover requirements. It should be understood that features ofthe failover-takeover embodiment are combined with selected features ofthe reconnect embodiments.

FIG. 4 illustrates schematically an example of the lifecycle of a gamein drawn in relation to a timeline 424. A player session 401 isinitiated by a player by inputting start commands via a user interfaceof the gaming machine. The player initiates a game and inputs a bet interms of a monetary value by means of some land of payment method suchas coins or an account transaction and thereby starts a first gamesession 402. The game session progresses in discrete steps herein calledgame rounds and exemplified with a first round 404 and a second round410. Each round in turn progresses in discrete steps called game phases.So for example, round 404 comprises three game phases 406,407 and 408.The transition between game phases is driven by game round events whichin different embodiments may have different content and differenttriggering mechanisms.

A game round event is triggered by an input that starts the generationof a set of associated elements of critical game session data thatdefines a game result preferably comprising the current bet value, acurrent generated random number and a current win value. The game roundevent would usually be triggered by a player making an input through anI/O interface such as a push button that conveys game commands like“Deal cards!” in a poker game.

In a simple example the game session data that defines a game result isgenerated in a gaming machine. The game round event is triggeredwhereupon the generation of this set of game session data is executedand the data set is completed. A confirmation of successful storage isgenerated, a presentation of the game result is output to the player andthe game phase is ended. In the client-server architecture describedabove, the client game module contacts the server game module with arequest in response to the triggering of a game round event. The servergame module executes the request and creates game result defining gamesession data for the current game phase. This data is stored in theserver database and a response comprising the game result defining datais transmitted to the client whereupon a presentation of the game resultis output to the player and the game phase is ended. The presentation ofthe game result to the player typically comprises updating a screendisplay of the gaming machine.

At the beginning of each game phase, in FIG. 4 illustrated with timeindicators A, B, C, D, the gaming machine, e.g. the client game module,is set in a waiting mode waiting for input from the player. When a gameround event is triggered by the player, the client game module and theserver game module executes the game rules, moves the game process tothe beginning of the next phase, stops and again goes into the waitingmode to wait for player input. From a gaming system macro perspectivethe execution of a game progresses in discrete steps where the gamephases are the smallest units of execution. An interruption is definedas the event that the gaming machine looses contact with the remote datastorage, or as the case may be in a client-server gaming system with theserver, for a predetermined amount of time during a game session. Theinterruption can occur at any point in time and may be intentional orunintentional as a result of a player action, a system operation actionor due to gaming machine failure, data communications failure or othersystem failure.

FIG. 5 shows a schematic sequence diagram that illustratescommunications between a gaming machine/client game module 502 and aremote data storage/server game module 504, as well as executed stepsoccurring during a game phase depicted in relation to time lines 520.The current game phase starts at 506 Time A and a waiting mode isentered and lasts until there is a game round event 512 comprisingtransmitting a request 512 from the gaming machine/client game module502. The request is received at the remote data storage/server gamemodule 504 whereupon in step 514 the request is executed and resultinggame session data is stored in a database residing in the data storage.In the simpler embodiment not involving a client-server configuration, aprocedure call to generate the game result defining data wouldcorrespond to the request. The execute and storage step 514 is completedat 508 Time A1 and thereafter in step 516 a response comprisingresulting game session data is transmitted from the remote datastorage/server game module 504 to the gaming machine/client game module502. After receipt of the response the gaming machine/client game module502 presents an output, e.g. an animation of a game outcome via thedisplay screen dependent on the result of the execution in the gameround event, which is terminated at 510 Time B with a transition intothe next game phase. The execution and storage step 514 is treated to beatomic in the sense that either it is completed or it is entirelyfailed. A game phase is considered to be complete when the execution andstorage step 514 has been completed, i.e. at 508 Time A1, whether or notthe following steps 516,518 up to 510 Time B have been completed when aninterruption occurs.

In the failover-takeover solution the game session is still valid in theclient gaming machine, and necessary identifications are preferablycomprised in the request messages or is retrieved from the gameapplication database or the back office database with informationcomprised in the request as a key. However, if the player session isfully interrupted the right of the player must be proven. The problem ofproving the right of a player to a certain interrupted game session isin one embodiment handled by issuing a reconnect voucher when a gamesession is interrupted. Each new player session is given a reconnectidentity code when it is initiated and, as previously mentioned, thestored nondeterministic inputs and execution results and outcomes makeup game session data that are associated with the reconnect identitycode. The reconnect identity code is preferably stored locally in theclient gaming machine as well as in the server. When a game session isinterrupted the client gaming machine prints out a reconnect voucherwith indicia that represent the game session identification code. Thisreconnect voucher is a value token representing the right of a player tothe interrupted game session and is also the key for identifying andretrieving the stored game session data. A game session is reconnectedand resumed by inputting the indicia via a reconnect voucher interfaceprovided on the client gaming machine.—For the case that the clientgaming machine is incapable of printing out a reconnect voucher, forexample due to a hardware or software breakdown, the invention providesfor the possibility to print out a reconnect voucher on a separategaming administration machine connected to the gaming system. In thiscase the proper reconnect identity code is found in the server databaseby means of the client identification and point in time for theinterruption. The indicia are in one embodiment printed and read in abar code format, but other indicia formats are of course conceivable.The printed reconnect voucher is useful when the players are anonymous.In other embodiments where the identity of the player is known, forexample using player card or player accounts it is convenient to storethe reconnect identity code associated to the player together withaccount information in a database or on a writable data storage means ona player card.

Embodiments of Interruption and Failover-Takeover Management

The invention is thus applied in a computerized gaming system adaptedfor operating a plurality of client gaming machine terminalscommunicatively coupled to a game application server. In a typicalsituation a number of gaming machine terminals are operatively coupledto and communicates with the game application server, new gaming machineterminals of different technical platforms log onto and log off from theserver as player sessions and game sessions are started and terminatedfrom each respective gaming machine terminal.

In a typical case in which the invention is employed a player hasstarted the initiation of a player session for a first gaming machineterminal, for example an interactive video terminal gaming machine at acasino venue. The player continues by starting the initiation of a gamesession via this first gaming machine terminal in communication with thegame application server and the game session is given an identificationcode called a game session identification code. Game session dataincluding game session identity information is stored in the serverdatabase together with gaming machine identity, thereby coupling saidfirst gaming machine terminal to said game session. The step ofinitiating a game session for a gaming machine would normally comprisethe player entering a player command via the input/output interface ofthe client gaming machine terminal for example by selecting a specificgame presented on a game selection menu on the display screen. Theselected client game module and corresponding server game module isstarted involving communication via the client API and the server API.

The communications between the gaming machine terminal and the gameapplication server as well as steps that are performed for realizing theinvention are described in the following exemplifying embodiment basedon the client-server configuration. Reference is made to the figures.The numbered list below is merely for reference purpose and does notnecessarily mean that the steps are performed in a sequencecorresponding to the indicated numerical order.

1. A player initiates a player session 401 on the client gaming machine2 by inputting a start command to the client game module 18 via anI/O-interface (22,24,28) which may be a traditional button or a buttonfield on a touch screen. The initiation of a player session wouldpreferably also comprise a monetary transaction for bets in the game,for example by the player adding a coin to a cash box 24 or by means ofan account transaction.

2. The client reconnect handler 30 comprised in the client gamingmachine 2 transmits a request for the reservation of a reconnectidentity code together with a client identification code foridentification of the specific gaming machine to the server. Thisrequest is received by the server reconnect handler 32 similarlycomprised in the game application server 4.

3. The request is executed by the server reconnect handler 32 whereby areconnect identity code is generated and stored associated with theclient identification code in a database 10.

4. A player session identity code is generated and associated with thereconnect identity code in the database 10, and a player session 402 isestablished.

5. The reconnect identity code is transmitted to the client reconnecthandler 30 and 10 is stored in local data storage 29 in the clientgaming machine 2 for the purpose of enabling communication of thereconnect identity code to the player.

6. A selected game is started by the player inputting a game startcommand to the game client module 18 via the game application programinterface 20 of the client gaming machine 2, and a request to start agame session is transmitted to the game application server 4.

7. A game session identity code is generated and stored associated withthe player session identity code, a game session 402 is established, afirst terminal session for the current gaming machine terminal 2 isestablished and coupled to the game session. A game phase 406 of a gameround 404 is entered.

8. The player triggers a game round event by giving a game related inputto the client game module 18 whereupon a request for a service istransmitted to the server game module 8.

9. The request is executed by the server game module 8 with the aid ofthe service functions of the server. The execution of this request wouldtypically comprise the generation of a random number RNG and thedetermination of an outcome dependent on the RNG.

10. Execution steps that are performed by the server game module 8 foreach request as well as results and outcomes of the execution make upgame session data, i.e. information that applies to the currentlyongoing game session. A subset of the game session data is the result ofa game round event and applies to the current game phase. A selection ofthese game session data are compiled and cashed, i.e. temporarily storedin data storage of the server 8. The selection may vary in differentexecution cases and embodiments, and would preferably comprise: the betvalue, the random number and the win value that are valid for thecurrent game phase. The selection of game session data may also compriseoptional pieces of information regarding the sequence of events calledevent history, each request and response, a pot at stake, the request,the response to the client gaming machine, game configurationinformation and a status indicator devised to indicate whether the gamesession has been completed or interrupted e.g. indicating lastevent=true/false.

11. The selection of game session data is stored in the database 10 andis transmitted with a response to the client gaming machine 2. Thereceived selection of game session data is cashed, i.e. temporarilystored in data storage of the client gaming machine 2.

12. The outcome of the game round event is presented to the player forexample via image output on a presentation screen of the client gamingmachine 2.

13. The steps 8-12 are normally repeated until a game round is ended,for example controlled by the player or by the game application serveraccording to predetermined rules.

14. As explained above, for each request the capability of receiving aresponse from the first used game application server withinpredetermined receiving conditions is determined. If the receivingconditions are not fulfilled, the communication from the client gamingmachine is redirected to a second game application server and the gamesession is reconstructed and continued.

15. If an interruption occurs, i.e. the client looses contact with theserver and the failover-takeover fails, the reserved reconnect identitycode that is temporarily stored in the storage 29 of the client gamingmachine 2 is for example printed out on a piece of paper or othersuitable carrier to make up a reconnect voucher output to the player.The reconnect voucher is in a currently preferred embodiment printedwith a bar code comprising the reconnect identity code and a statusindicator for the interrupted game, and some text information forexample about the gaming venue.

For the purpose of reconstructing the game session in thefailover-takeover procedure and resume the game session the game sessionand the game session data is found by means of the game session identitycode as a key input to the game server database as explained above.

The procedure for failover-takeover in different embodiments furthercomprises a selection of the following. When the client gaming machineis communicatively coupled to the second game application server and ithas been determined that the second game application server shall takeover the game session a player session corresponding to the one in theclient gaming machine is initiated in the game application server.Preferably, only the server side state of the game session, that is thestate in the game application server, is reconstructed by means of thegame session data.

For the purpose of reconnecting the game and resume the game session afolly interrupted game is found by means of the reconnect identity codeas a key input to the gaming system. The reconnect procedure is hereexplained by way of example with the reconnect voucher embodiment inwhich the player enters a reconnect voucher in a bar code reader of aclient gaming machine of the gaming system. It should be understood thatalso other means of conveying the reconnect identity code to the gamingsystem are within the inventive concept. The reconnect voucher can forexample be inserted in the same gaming machine in which the game wasinterrupted, a different gaming machine or in an administrative clientterminal. The administrative client terminal is preferably devised onlyto be able to refund money or issue a monetary credit.

The procedure for reconnection comprises in one embodiment a selectionof the following steps.

1. If the client gaming machine in which the game was interrupted loginswith the game application server and a new player session is initiated,the client handler 36 of the game application server detects in a checkprocedure that this particular client gaming machine has had aninterrupted game. The client identification code is associated with theprevious reconnect voucher for that specific client and the stored gamesession data, and a new reconnect identification code is reserved andtransmitted to the client gaming machine to replace the previous andactivated reconnect identity code.

2. If a player starts a player session in a different client gamingmachine, a new reconnect identification code is reserved in the normalmanner.

3. The player inputs a reconnect voucher into the bar code reader of theclient gaming machine, and the information on the reconnect voucher isread and treated under the control of the client control module 34 andthe client reconnect handler 30. The information on the reconnectvoucher is transmitted with a request to the game application server.

4. The game application server checks the status of the reconnectvoucher and determines by means of the status indicator and informationstored in the server database whether there is an interrupted gamesession.

5. If there is a monetary credit only, the money is credited to theplayer for a new game or as a refund.

6. If there is un-synchronized money, a synchronization procedure isexecuted.

7. If there is an interrupted game, the game is reconstructed andpresented to the player in the state in which it was interrupted.

The reconstruction of an interrupted game can be implemented in variousmanners.

One embodiment comprises of the following steps.

1. With the reconnect identity code as a key, the associated gamesession data is retrieved from the server database under the control ofthe server reconnect handler 30.

2. The server reconnect handler 30 uses the retrieved game session dataas input to the server game module 8 and generates the last responsefrom the server game module that should have been transmitted to theclient gaming machine unless the interruption had occurred. In differentembodiments

3. Reconnect information comprising game session data is compiled andtransmitted to the client reconnect handler 30 of the client gamingmachine. In one embodiment this reconnect information comprises the gameidentifications for the server game module and the client game module,game session data including an initial monetary balance, all requestsand all responses of the event history.

4. In the client gaming machine, the client game module is initiated andthe game is executed by the client reconnect handler 30 using the gamesession data as input up to the last completed game phase before thepoint of interruption, called the reconnect target point. In contrastwith the normal execution of a game, the requests that are generated inthe reconnect execution are discarded and after each request the game ispresented with the corresponding response from the game session data.Since the client reconnect handler 30 has access to all the requests aswell as the responses to the requests it is enabled that a check of aproper reconstruction of the game session can be performed. Preferably,the game is executed up to the reconnect target point without presentingthe intermediate results to the player in order to speed up theexecution and avoid confusing the player.

5. After the last event and thereby the last completed game phase hasbeen executed, the corresponding result and state of the game ispresented to the player via the graphical user interface and the gameenters a waiting mode waiting for the next input from the player.

6. The game continues in a normal manner.

The invention has been described by way of exemplifying embodiments, butnaturally there are various manners of realising the invention withinthe scope of the claims.

1. A method of operating a computerized gaming system comprising aclient gaming machine, a first group of one or more game applicationservers operatively coupled to a first database storage structure and asecond group of one or more game application servers operatively coupledto a second database storage structure, the method comprising: uponestablishing between the client gaming machine and a first gameapplication server from the first group a game session associated with agame session identity code, associating data generated in relation tooperating the game session with the game session identity code, thusgiving rise to game session data, and continuously storing the gamesession data in the first database storage structure; receiving, by asecond game application server of the second group, a connection requestissued responsive to receiving data indicative of an incapability of thefirst game application server to respond to a game request sent by theclient gaming machine during operating the game session, the connectionrequest is associated with the game session identity code; requesting,by the second game application server from the second database storagestructure, game session data corresponding to the game session identitycode associated with the connection request; requesting, by the seconddatabase storage structure from the first database storage structure,game session data corresponding to the game session identity codeassociated with the connection request received by the second gameapplication server; using game session data corresponding to the gamesession identity code to determine, by one of the first database storagestructure and the second database storage structure, if the game sessionmeets a takeover criteria; and when the game session meets the takeovercriterion, taking over the game session by the second database storagestructure and forwarding game session data received from the firstdatabase storage structure and associated with the game session identitycode to the second game application server for reconstructing the gamesession by the second game application server.
 2. The method of claim 1further comprising issuing, by one of the first database storagestructure, the second database storage structure and the second gameapplication server, a notification to the first game application serverthat the game session has been taken over by the second applicationserver.
 3. The method of claim 2 further comprising: responsive toreceiving the notification, removing by the first game applicationserver any cached data related to the game session data.
 4. The methodof claim 1, wherein data indicative of an incapability of the first gameapplication server to respond to a request sent by the client gamingmachine are received by the first game application server from a loadbalancer operatively connected to the client machine, to the first gameapplication server and to the second game application server.
 5. Themethod of claim 1, wherein the incapability of the first gameapplication is determined in accordance with predetermined receivingcondition is related to at least one parameter selected from the groupconsisting of: time of response from the first game application server;status parameter; and quality of response from the first gameapplication server.
 6. The method of claim 1, wherein the game sessiondata comprise data indicative of the client gaming machine.
 7. Themethod of claim 1, wherein the game session progresses in game roundsdriven by game round events, and game session data comprise dataassociated with each of the game round events and defining the gameresults.
 8. The method of claim 7, wherein data associated with a gameround are selected from a group consisting of data indicative of a betvalue corresponding to the game round, data indicative of a generatedrandom number corresponding to the game round and data indicative of awin value corresponding to the game round, data indicative of gamesession event history and game configuration information.
 9. The methodof claim 1, wherein the game session is reconstructed so that thereconstructed game session is characterized by the same result, outcomeand output as the original game session.
 10. The method of claim 1,wherein the game session does not meet the takeover criterion when thereis an on-going processing related to the connection request in at leastone of: the first game application server and the first database storagestructure.
 11. The method of claim 1, wherein the second gameapplication server is selected by a load balancer operatively connectedto the first group and the second group of the game application servers,the selecting provided in accordance with predetermined priority rules.12. The method of claim 1 further comprising issuing, by the clientgaming machine, a reconnect voucher when the game session does not meetthe takeover criterion because of a game session interruption, thereconnect voucher comprising data indicative of a reconnect identitycode associated with the game session identity code.
 13. The method ofclaim 12 further comprising: using the reconnect voucher forinitializing a reconnect request from the client machine to the firstgame application server and/or the second game application server;responsive to the reconnect request, retrieving by a respective gameapplication server data associated with the game session identity codecorresponding to respective reconnect identity code, the data stored inthe first database storage structure prior to the game sessioninterruption; reconstructing, by the respective game application server,the game session up to a point of interruption.
 14. A computerizedgaming system comprising a client gaming machine operatively coupled toa first group of one or more game application servers operativelycoupled to a first database storage structure and to a second group ofone or more game application servers operatively coupled to a seconddatabase storage structure, wherein: the client gaming machine isconfigured: to establish a game session with a first game applicationserver from the first group and to continuously store the game sessiondata in the first database storage structure, wherein the game sessionis associated with a game session identity code, and wherein the gamesession data comprise data generated in relation to operating the gamesession and are associated with the game session identity code; and whenthe first game application server is incapable to respond to a gamerequest sent by the client gaming machine during operating the gamesession, to issue to a second game application server of the secondgroup a connection request associated with the game session identitycode; the second game application server is configured to request fromthe second database storage structure, responsive to the connectionrequest received from the client gaming machine, game session datacorresponding to the game session identity code associated with theconnection request; the second database storage structure is configuredto: request from the first database storage structure game session datacorresponding to the game session identity code associated with theconnection request received by the second game application server; usegame session data corresponding to the game session identity code todetermine if the game session meets a takeover criteria; and when thegame session meets the takeover criterion, to take over the game sessionfrom the first database storage structure and to forward game sessiondata received from the first database storage structure and associatedwith the game session identity code to the second game applicationserver for reconstructing the game session by the second gameapplication server.
 15. The system of claim 14, wherein the first gameapplication server is configured to remove any cached data related tothe game session data responsive to receiving the notification that thegame session has been taken over by the second application server, thenotification issued by one of: the first database storage structure, thesecond database storage structure and the second game applicationserver.
 16. The system of claim 14, wherein the client gaming machine isfurther configured to issue a reconnect voucher when the game sessiondoes not meet the takeover criterion because of a game sessioninterruption, the reconnect voucher comprising data indicative of areconnect identity code associated with the game session identity code.17. The system of claim 14, further comprising a plurality of databaseservers organised in at least one of: the first database storagestructure and the second database storage structure.
 18. Anon-transitory computer readable storage medium having instructionsthat, when executed by a processing device, cause the processing deviceto perform operating a computerized gaming system comprising a clientgaming machine, a first group of one or more game application serversoperatively coupled to a first database storage structure and a secondgroup of one or more game application servers operatively coupled to asecond database storage structure, the operating comprising: uponestablishing between the client gaming machine and a first gameapplication server from the first group a game session associated with agame session identity code, associating data generated in relation tooperating the game session with the game session identity code, thusgiving rise to game session data, and continuously storing the gamesession data in the first database storage structure; receiving, by asecond game application server of the second group, a connection requestissued responsive to receiving data indicative of an incapability of thefirst game application server to respond to a game request sent by theclient gaming machine during operating the game session, the connectionrequest is associated with the game session identity code; requesting,by the second game application server from the second database storagestructure, game session data corresponding to the game session identitycode associated with the connection request; requesting, by the seconddatabase storage structure from the first database storage structure,game session data corresponding to the game session identity codeassociated with the connection request received by the second gameapplication server; using game session data corresponding to the gamesession identity code to determine, by one of the first database storagestructure and the second database storage structure, if the game sessionmeets a takeover criteria; and when the game session meets the takeovercriterion, taking over the game session by the second database storagestructure and forwarding game session data received from the firstdatabase storage structure and associated with the game session identitycode to the second game application server for reconstructing the gamesession by the second game application server.